
CCP Masterplan
C C P Alliance

|
Posted - 2010.10.20 17:10:00 -
[1]
Originally by: Etil DeLaFuente Edited by: Etil DeLaFuente on 20/10/2010 06:08:42
Quote: The side effect of this is that fighter bombers are the "spawn of evil" in server performance terms. Team Gridlock who are leading the war on lag effort identified them as a major contributor to fleet fight lag as is demonstrated below. Not only are they drones which usually come in packs of 20 per ship but they fire missiles which all have to be tracked in the inventory and physical scene within the game.
I'd like to know what's ccp internal process when it comes to give us new features, especially in terms of performance, server side impact etc.. It looks like no one in charge to me. This major drawback about SC could have been detected at design time.
What about regular fighters and/or drones ? Do they have the same kind of issue or is it just the fact that fighter bombers fire missiles ?
I can't speak about the original design process of Super-carriers, as I wasn't here at the time. However I am on Team Gridlock, which identified the specific load issues caused by Fighter-Bombers. The main reason FBs are so expensive is the way their load scales: One SC can launch 20 of them, each of which fires a torpedo every 15 seconds. Each torpedo has quite a long flight time. The end result is a small number of players can generate a disproportionately large number of items that must be tracked through the physics/inventory/damage systems. (Skills/modules can push the numbers even further, which has knock-on effects for load) Regular fighters/drones don't scale in this way: Firstly their damage mechanism is an instantaneous effect that has little load on the physics system (it mainly needs just distance and transversal data). Secondly they don't add extra entities into space. Thirdly (in the case of regular drones) you can't launch so many of them.
This is actually the first example of Gridlock pushing the design team to make content changes aimed at reducing load. Everything else that we have released so far is behind-the-scenes optimisations which shouldn't have gameplay changes. Those kind of improvements are great due to the fact we can roll them out with minimal red-tape. There are some longer-term changes we are pushing, but those might require work from art, design, gameplay/UI programmers to complete to a releasable standard. Naturally this means a longer lead-time, but for potentially the greatest gains.
As for new brand-new features, our team makes sure that others are aware of load implications for their new ideas. Sometimes we'll ask them to go back and rethink a proposal. Combine this with the fact we can now do pre-emptive load-testing (thanks to the thin-client tech) and we hope to catch and prevent issues earlier.
|